Hello SkyDemon team,

here's my little suggestion that I think would improve the usability of SkyDemon Flight Planning for PC (I'm using SD 3.3.2 on Windows 8.1):

1. Launch SkyDemon plan.
2. Open or create a route.
3. Click on any secondary pane (with Auto Hide = off), e.g. Virtual Radar, and scroll the mouse wheel: the zoom level of the Virtual Radar pane will change, as expected.
4. Now, without clicking, move the mouse pointer over to the main map pane and scroll the wheel.

This concept of the scroll event that should always follow the mouse pointer, regardless of which window or pane is selected, is a real PITA on Windows, where it is applied inconsistently (e.g. Adobe Reader and Google Maps on Chrome correctly respond to it, but Windows Explorer itself doesn't). On other platforms (e.g. Linux/Gnome) it is the standard, and I think it makes for a much more natural user interface.

What do you guys think? It's a detail, I know, but attention to details matters.

I'd go further still and comply with the semi-standard:

* Scroll - pan vertically
* Shift-scroll - pan horizontally
* Ctrl-scroll - zoom

It makes zipping around a Visio drawing so easy that I really miss it in applications which don't support it.

Not sure about that... the map applications most people arguably are familiar with, Google maps, Bing Maps etc, all adopt the 'Scroll = Zoom' convention, and I'm glad SkyDemon follows it too. It's a parallel issue, anyway.

In Windows, the mouse wheel scroll events are delivered to the window with the focus.

We could depart from that practice in theory to do what you're suggesting, but it would be a real pain. We'd have to intercept those messages from all other windows, check if the pointer was over the map, and then steal them for the map's usage. I don't think it's worth doing.

Just to clarify: the logic I have in mind would be as follows (applicable in general to all panes, not just the map):

• When a mouse wheel scroll event occurs:
• If the mouse pointer is off the SD window completely (e.g. over the desktop), ignore the event altogether.
• else check if the mouse pointer is over the pane that has focus.
• If so, deliver the event to that pane normally, otherwise check which pane has got the mouse pointer over it and deliver the event to that pane instead.

This way the user would always see scrolling whatever the mouse is pointing to, as opposed to the pane that has focus (which may not be any more the one the user is looking at).

OK, it's a low-priority one, but can it make it onto the wishlist anyway?